This invention relates to the computerized playback of musical segments and their constituent tracks. Specifically, the invention relates to playing multiple instances of given segment concurrently with each other.
Musical performances have become a key component of electronic and multimedia products such as stand-alone video game devices, computer-based video games, computer-based slide show presentations, computer animation, and other similar products and applications. As a result, music generating devices and music playback devices are now tightly integrated into electronic and multimedia components.
Musical accompaniment for multimedia products can be provided in the form of digitized audio streams. While this format allows recording and accurate reproduction of non-synthesized sounds, it consumes a substantial amount of memory. As a result, the variety of music that can be provided using this approach is limited. Another disadvantage of this approach is that the stored music cannot be easily varied. For example, it is generally not possible to change a particular musical part, such as a bass part, without re-recording the entire musical stream.
Because of these disadvantages, it has become quite common to generate music based on a variety of data other than pre-recorded digital streams. For example, a particular musical piece might be represented as a sequence of discrete notes and other events corresponding generally to actions that might be performed by a keyboardist-such as pressing or releasing a key, pressing or releasing a sustain pedal, activating a pitch bend wheel, changing a volume level, changing a preset, etc. An event such as a note event is represented by some type of data structure that includes information about the note such as pitch, duration, volume, and timing. Music events such as these are typically stored in a sequence that roughly corresponds to the order in which the events occur. Rendering software retrieves each music event and examines it for relevant information such as timing information and information relating the particular device or xe2x80x9cinstrumentxe2x80x9d to which the music event applies. The rendering software then sends the music event to the appropriate device at the proper time, where it is rendered. The MIDI (Musical Instrument Digital Interface) standard is an example of a music generation standard or technique of this type, which represents a musical performance as a series of events.
There are a variety of different techniques for storing and generating musical performances, in addition to the event-based technique utilized by the MIDI standard. As one example, a musical performance can be represented by the combination of a chord progression and a xe2x80x9cstylexe2x80x9d. The chord progression defines a series of chords, and the style defines a note pattern in terms of chord elements. To generate music, the note pattern is played against the chords defined by the chord progression.
A xe2x80x9ctemplatexe2x80x9d is another example of a way to represent a portion of a musical performance. A template works in conjunction with other composition techniques to create a unique performance based on a musical timeline.
These different techniques correspond to different ways of representing music. When designing a computer-based music generation and playback system, it is desirable for the system to support a number of different music representation technologies and formats, such as the MIDI, style and chord progression, and template technologies mentioned above. In addition, the playback and generation system should support the synchronized playback of traditional digitized audio files, streaming audio sources, and other combinations of music-related information such as lyrics in conjunction with sequenced notes.
U.S. patent application Ser. No. 5,753,843, issued to Microsoft on May 19, 1998, describes a system for generating music in accordance with the techniques described above. In addition, a concurrently-filed United States Patent Application, entitled xe2x80x9cTrack-Based Music Performance Architecturexe2x80x9d by inventors Todor C. Fay and Mark T. Burton, describes a music generation architecture that easily accommodates various different types of music generation techniques. In the system described in that application, a piece of music is embodied as a programming object, referred to as a segment object, that represents a segment of music. The segment object has an interface that can be called by a playback program to play identified portions of the segment. Each segment comprises a plurality of tracks, embodied as track objects. The track objects are of various types for generating music in a variety of different ways, based on a variety of different data formats.
Each track, regardless of its type, supports an identical interface, referred to as a track interface, that is available to the segment object. When the segment object is instructed to play a music interval, it passes the instruction on to its constituent tracks, which perform the actual music generation. In many cases, the tracks cooperate with each other to produce music. The cited application describes inter-track object interfaces that facilitate communication between the tracks, thereby allowing one track to obtain data from another track. This is used, for example, by a style track in order to obtain chord information from a chord progression trackxe2x80x94the style track needs the chord information for proper interpretation of notes within the style track, which are defined in terms of chord elements.
It has been found that it would be desirable to be able to initiate multiple instances of a given segment, for playback during overlapping times. Because a segment is implemented as a set of tracks, each segment instance would correspond to a set of track instances. At any given time, each track instance would be playing a different portion of the track""s music.
In most cases, however, it is not feasible to use a single track object to represent or play multiple instances of a given musical track. This is because playing a track usually involves maintaining at least a minimal amount of changing state information. In a simple case, such state information might comprise the temporal point within the track at which playback is currently taking place. This changes with time, as playback of the track proceeds. In more complex situations, tracks might have a need for much more extensive state data. For example, a track might have different sequence and chord variations that are chosen when the track is initiated. With a track like this, each track instance might have chosen a different sequence and chord variation, and thus require state data to indicate the particular choice of sequence and chord for each instance. As another example, a track might have characteristics that change over time, depending on some sort of environmental or user input. In this case, the track would need to maintain information about previous inputs to determine its current characteristics.
It would be possible to solve this problem by simply instantiating duplicate copies of each set of track objects, so that each segment instance would corresponds to a different set of actual track objects. However, this would quickly increase memory requirements beyond reasonable levels. Accordingly, there is a need for a different method of playing multiple segment instances.
In accordance with the invention, a track manager manages playback of a segment and its tracks. In response to a request for a new instance of the segment, the track manager signals each of the segment""s tracks to initialize itself with new state information. The tracks pass this state information back to the track manager.
During track playback, the track manager makes repeated calls to the individual tracks to play sequential portions of their music. Each track, rather than maintaining its own state information, receives its state information from the calling track manager. In this way, the track manager can maintain different state information corresponding to different track instances, which in turn correspond to different instances of music segments. By providing different state information at different times to the tracks, the track manager can play multiple segment instances without having to duplicate the individual tracks.
As another aspect of the invention, track manager is implemented as a single segment object in conjunction with multiple state objects corresponding to different segment instances. The state objects keep track of state data corresponding to different segment and track instances. The state objects are called by a performance manager or object to play the different segment and track instances at different times.